Hot Super Models/Hot Super Models.iso/amiga/gifmachn/gifmachn.dcs

Text File | 1991-09-18 | 9KB | 183 lines

                                GIFMachine

                 Copyright 1990 by Christopher A. Wichura
                           ([e-mail])


Legal mumbo jumbo:

GIFMachine is not in the public domain.  All source files, along with the
resulting executable, are copyright by C. Wichura.  You may not sell
GIFMachine.  The only allowed charge that may be placed on GIFMachine is
for media and/or mailing costs.

GIFMachine may be freely redistributed via BBSs, InterNet/Usenet, and disk
libraries such as Fred Fish's, as long as the archive is not modified.
Disk magazines and services that charge extra for file transfers may not
distribute GIFMachine.

In using GIFMachine, you accept the responsibility for any damage or loss of
productivity/money that may occur through or during its use.  C. Wichura is
not and can not be held accountable.

                            What is GIFMachine?
                            ~~~~~~~~~~~~~~~~~~~
GIFMachine is a program that converts pictures stored in the CompuServe GIF
(Graphics Interchange Format) format into IFF SHAM format.  There are very
few programs that do this, and most have many problems (not that GIFMachine
doesn't either -- see below).

For a long time, I used a program called ShamSharp to convert GIFs to IFF
format.  ShamSharp was the only thing I would even consider using (execpt
for ASDG's The Art Department, a very fine commercial product!).  However,
there were a number of things about it that irked me.

   1)  If a picture had >16 colours and a width >320, ShamSharp would
       __ALWAYS__ halve the width of the image.  Not only that, but it
       did so by simply skipping every other pixel of the original GIF.
       This resulted in a tremendous loss in resolution.

       I, myself, would rather have the entire picture converted and be
       able to use my favorite viewer (Mostra, by S. Vigna) to scroll
       around the image.  Thus, by default, GIFMachine will not halve
       the picture's width.  There is a command line switch to make it
       do so, however, in which case it actually thinks about it a bit
       rather than just dropping the odd pixels.

   2)  If an image had more than 400 lines in it, ShamSharp would
       GURU the system if the SHAM mode flag was used.  GIFMachine handles
       large pictures well (that was one of the primary concerns I had
       while writing it) and has been tested with images as large as
       1152x890!

   3)  ShamSharp would write bad IFF files for me on a regular basis.  I
       suspect this is because of some subtle bug in the cmpByteRun1
       compression routine ShamSharp uses.  Anyway, GIFMachine has yet to
       write a bad IFF on me.  (Cross Fingers, Cross Fingers :-)

GIFMachine also offers the user the ability to automatically remove a
border area in a picture, among its other toys.  (I just hate it when you
have an image floating in the middle of the screen with inches of nothing
around it.)

                          Drawbacks of GIFMachine
                          ~~~~~~~~~~~~~~~~~~~~~~~
If you are looking for speed, go someplace else.  GIFMachine was written
with the idea of getting the best possible image from a GIF file, not as
something to view GIFs in a quick and dirty manner.  Usually what I do is
use something like HAMGIF to see if the GIF is actually worth the effort
and then convert a series of GIFs in one shot by specifying multiple
filepspecs.  On a stock 500, the average picture takes around 25 minutes to
convert (half that if the image is interlaced, which is often the case when
the width is halved).

GIFMachine knows how to write only one thing: SHAMs.  If a picture only
uses <= 16 colours, SHAM is not needed.  It would be much faster to write a
normal IFF and skip the SHAM conversion calculations.  In such a case, it
would be better to go back and use something like ShamSharp.  (Note that
this has changed with GIFMachine v2:  You can now write 24bit deep ILBMs as
well.)

The only viewer I know of that properly handles SHAMs with >400 lines is
Mostra.  SuperSham 3.2 (?) will display the image, but does not allow
scrolling around.  The latest version of Christian Weber's ShowIFF
(included in the v18.? distribution of his iff.library) will also display
SHAMs and let one scroll around.  However, he does not rebuild the copper
list during vertical scrolling and thus the image turns to muck if one
scrolls down.

                             Using GIFMachine
                             ~~~~~~~~~~~~~~~~
GIFMachine requires that you have KickStart 2.0 or greater (hey, I have a
3000 and SAS C with 2.0 includes so I dumped ARP in favor of 2.0).  It also
requires a fair amount of RAM (though it does not have to be CHIP RAM or
contiguous).  Alas, memory requirements have gone up with v2; the primary
image now requires three bytes to store a pixel instead of two.   A 640x480
GIF now requires about a meg of free memory to convert.

GIFMachine uses the 2.0 ReadArgs() argument parser.  Thus, one can always
enter `GIFMachine ?' on the command line for help.  GIFMachine can not be
run from the WorkBench.

GIFMachine accepts the following arguments:

<filespec1> ... <filespecN> [TO <directory or filespec>] [ALL]
                            [NOBORDER <line thresh>] [XCOMP] [DITHER]
                            [XFLIP] [YFLIP] [DEEP] [NOCOUNT]
                            [BUFSIZE <Size in KBytes>]

Each filespec may contain any valid 2.0 wildcards (really regular
expressions).

The TO option allows one to specify where to put the IFFs.  If not given,
they will be placed in the current directory.  It is generally advised that
TO point at a directory.  However, if you are converting only a single GIF
file then there is no reason one can not specify a full filespec.

The ALL option will cause GIFMachine to recursively descend into any
directories while matching filespecs.

The NOBORDER option instructs GIFMachine to remove the border area from an
image.  It takes, as its <line thresh> parameter, an integer between 0 and
100 that indicates what percentage of a line can differ from the border
colour and still have the line removed.  This option has been slightly
modified in the v2 release:  Before, GIFMachine assumed that the value at
coordinate 0,0 was the colour of the entire border area.  This is not
always the case, however.  Take, for example, a GIF with the image right up
in the upper left corner with a large empty region to the right and below
of it.  Such an image would have almost none of the offending border
removed.  GIFMachine will now attempt to run the stripper four times, using
each of the four corners' colour for the border check.  For the most part,
this does not slow this function down because a border check is aborted as
soon as the <line thresh> is exceeded and GIFMachine moves to the next
corner.

The next option, XCOMP, tells GIFMachine to halve the width of images.

When the DITHER option is specified, a boustrophedonic Floyd-Steinberg
error diffusion algorythm will be used when reducing the colour palette to
12 bits.  This can help eliminate colour banding that occurs in places
where subtle shadows occur.

The XFLIP and YFLIP options will flip the image horizontally and
vertically, respectively.

The DEEP option will cause GIFMachine to write a 24bit deep ILBM instead of
a SHAM file.  The DITHER option will be ignored in this mode, however.
Writing deep ILBMs if much faster than writing SHAMs because no
computations need to be made.  Please note that files written with this
option in effect can be quite large.  Expect a 640x480 XCOMPed image to be
over 400k in length, for example.

The NOCOUNT option will suppress the printing of line numbers while various
operations are being performed.  This can speed the conversion process up a
tad, as GIFMachine does not have to wait on the console to display
messages.

The final option, BUFSIZE, allows one to change the read buffer size used
when decompressing GIFs.  It defaults to two Kbytes.  The argument is
specified in number of Kbytes, not bytes.  Thus, if you have memory to burn
and want a large buffer you could specify a BUFSIZE 100 and you would get a
buffer 100k in size.  This command does not effect the writing of the IFF
file, however.

Note that if GIFMachine determines that the image can be written interlaced
(depends on aspect ratios) then it will work on two lines at a time instead
of one.  This is because the SHAM format only changes the base colours
every other line when displaying interlaced images.

GIFMachine and GIF89a compatibility:  GIFMachine should be able to read any
GIF file written under the GIF89a specs.  GIFMachine does not, however,
perform aspect corrections or process Plain Text Extensions (for obvious
reasons), Graphic Control Extensions, or Application Extensions.
GIFMachine will, however, detect the new Comment Extension blocks.  The
messages contained in such blocks will be stored and output as ANNO chunks
when the IFF file is being written.

-=> CAW

                    Christopher A. Wichura
                    5450 East View Park
                    Chicago, Il  60615